• Add new IntermediateCall schema object for modeling intermediate stops
• Add intermediateCalls array property to Leg schema
• Enable grouping of non-transhipment calls within single leg
• Support collapsible UI representation of intermediate stops

Add IntermediateCall schema and leg property

• Added new IntermediateCall schema object with properties for transport call reference, facility
 type, location, and arrival/departure times
• Added intermediateCalls array property to Leg schema to support intermediate non-transhipment
 calls
• Included comprehensive documentation explaining that intermediate calls are grouped within a
 single leg without transhipment
• Enables UI consumers to present intermediate calls as collapsed or expanded elements

cs/v1/CS_v1.0.3.yaml

Description

IntermediateCall.transportCallReference is described as “the unique reference for the arrival
transport call”, which is incorrect for an intermediate call and conflicts with the spec’s generic
TransportCall.transportCallReference wording; this can lead implementers to populate/interpret the
wrong reference.

Code

cs/v1/CS_v1.0.3.yaml[R1671-1676]

+        transportCallReference:
+          type: string
+          example: SR11111X-9321483-2107W-NLAMS-ACT-1-1
+          maxLength: 100
+          description: |
+            The unique reference for the arrival transport call. It's the vessel operator's responsibility to provide the Transport Call Reference, other parties are obliged to pick it up and use it. It can take the form of Port Call References as defined in OVS Definitions Document, or alternatively a reference as defined by the vessel operator.

Evidence

The new schema documents IntermediateCall.transportCallReference as an *arrival* transport call
reference, but IntermediateCall represents calls *between* a leg’s departure and arrival.
Elsewhere in the same spec, the generic TransportCall.transportCallReference is correctly
described as “for a transport call” (not arrival-specific), and arrival/departure-specific wording
is only used in PlaceOfArrival/PlaceOfDeparture where it matches the object’s semantics.

cs/v1/CS_v1.0.3.yaml[1663-1676]
cs/v1/CS_v1.0.3.yaml[973-990]
cs/v1/CS_v1.0.3.yaml[714-773]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`IntermediateCall.transportCallReference` currently says it is the unique reference for the **arrival** transport call, which is misleading for an intermediate call and inconsistent with the spec’s generic `TransportCall.transportCallReference` definition.

### Issue Context
Intermediate calls are explicitly defined as calls **between** the leg `departure` and `arrival`, so the field description should be neutral (transport call at this intermediate location) rather than arrival-specific.

### Fix Focus Areas
- cs/v1/CS_v1.0.3.yaml[1671-1676]

### Suggested change
Update the description to align with `TransportCall.transportCallReference`, e.g.:
- “The unique reference for a transport call …”
or
- “The unique reference for the transport call at this intermediate location …”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

IntermediateCall has no required fields, so an empty object {} is schema-valid even though it
cannot represent a real intermediate call (no location and no times), weakening validation and
generated client/server contracts.

Code

cs/v1/CS_v1.0.3.yaml[R1663-1705]

+    IntermediateCall:
+      title: Intermediate Call
+      type: object
+      description: |
+        An intermediate call between `departure` and `arrival` in the current leg. 
+
+        The cargo remains on the same planned transport, and no transhipment takes place at this location.
+      properties:
+        transportCallReference:
+          type: string
+          example: SR11111X-9321483-2107W-NLAMS-ACT-1-1
+          maxLength: 100
+          description: |
+            The unique reference for the arrival transport call. It's the vessel operator's responsibility to provide the Transport Call Reference, other parties are obliged to pick it up and use it. It can take the form of Port Call References as defined in OVS Definitions Document, or alternatively a reference as defined by the vessel operator.
+        facilityTypeCode:
+          description: |
+            The code to identify the specific type of facility. The code indicates which role the facility plays during the transportCall.
+            - `BORD` (Border)
+            - `CLOC` (Customer Location)
+            - `COFS` (Container Freight Station)
+            - `OFFD` (Off Dock Storage)
+            - `DEPO` (Depot)
+            - `INTE` (Inland Terminal)
+            - `POTE` (Port Terminal)
+            - `PBPL` (Pilot Boarding Place)
+            - `BRTH` (Berth)
+            - `RAMP` (Ramp)
+            - `WAYP` (Waypoint)
+          example: POTE
+          maxLength: 4
+          type: string
+        location:
+          $ref: '#/components/schemas/Location'
+        arrivalDateTime:
+          type: string
+          format: date-time
+          example: '2025-01-14T09:21:00+01:00'
+          description: The local date and time, when the arrival will take place.
+        departureDateTime:
+          type: string
+          format: date-time
+          example: '2025-01-14T09:21:00+01:00'
+          description: The local date and time, when the departure will take place.

Evidence

IntermediateCall defines properties but no required: array, meaning all fields are optional by
schema rules. Comparable “place + time” structures in the same spec (e.g., PlaceOfReceipt and
PlaceOfArrival) explicitly mark key fields as required (facilityTypeCode/location/dateTime), so
leaving IntermediateCall fully optional is inconsistent and allows meaningless intermediate call
entries.

cs/v1/CS_v1.0.3.yaml[1663-1706]
cs/v1/CS_v1.0.3.yaml[646-680]
cs/v1/CS_v1.0.3.yaml[714-756]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`IntermediateCall` has no `required` list, so empty objects are valid intermediate calls. This undermines validation and makes the new `Leg.intermediateCalls` structure ambiguous/unreliable.

### Issue Context
Similar schemas in this spec (e.g., `PlaceOfReceipt`, `PlaceOfArrival`) declare required location/time fields. An intermediate call likewise needs a location and timing to be meaningful.

### Fix Focus Areas
- cs/v1/CS_v1.0.3.yaml[1663-1706]

### Suggested change
Add a `required:` array to `IntermediateCall`, at minimum requiring:
- `facilityTypeCode`
- `location`
- `arrivalDateTime`
- `departureDateTime`

Keep `transportCallReference` optional if it is not guaranteed to be known for all intermediate calls (otherwise include it as required as well).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools